Installing WCM on web servers

Note: Do not perform this procedure on your production iMIS application server if you installed it using the Complete option of the iMIS Installer, because the supporting code for WCM is already installed. Only perform this procedure on standalone web servers that are used for hosting iMIS sites.

Note: The term "web server" refers to any server that hosts iMIS sites, whether it is inside your network firewall (for private intranet sites) or outside your network firewall (for public-facing sites).

Run the iMIS installer on each web server and use the Custom installation option to install only the Content Management component. This installs only the code needed to support iMIS sites and enable them to interact securely with your iMIS database. It also installs the publishing service used for publishing new content to the iMIS sites on this web server, defines a corresponding publishing server in the iMIS database, and it sets up a dedicated IIS application in the IIS Default Web Site, to use for hosting iMIS sites.

■ Be sure to configure your networks and servers to run efficiently. See Best Practices for additional information.

■ You are given an opportunity to change the default name WCM for the IIS application that will host your iMIS sites. You would do this if you prefer that the URLs to each of your iMIS sites contain a different application segment other than /wcm/ (for example, http://www.myorg.org/usa/mywebsite/ instead of the default http://www.myorg.org/wcm/mywebsite/). Whether you rename the application or leave it at the default value, you must communicate the URL that resolves to this new application to the people who define your iMIS sites, because they must specify this URL in the URL(s) pointing to the IIS website root when defining sites.

■ The standard installation of WCM is designed to enable the installed IIS application to host multiple iMIS sites with a minimum of required hard drive space. If you prefer to simplify the URLs for your iMIS sites by using one IIS application per iMIS site or even by using one IIS web site per iMIS site, you can do so only after you have completed the standard installation of WCM. The process requires some manual steps described below in the Tips section, and requires roughly 1.6GB of additional disk space per each additional IIS application or IIS web site.

■ When prompted to specify a Publishing Server Code, you must specify a new value that is unique among all your iMIS application servers and WCM web servers. Do not accept the default value of A because this was probably already used when your iMIS application server was installed.

■ When prompted to specify an Indexing Catalog Name, you can safely leave it at the default value unless you use Microsoft Index Server for other IIS applications on the server, and you want to combine the search data from several IIS applications into a single catalog. In this case, you would specify the name of that central Index Server catalog.

Note: On iMIS application servers that were installed with the Complete option, or that were Custom-installed with both the Content Management component and the iMIS application component, the iMIS application hosts the staff views of iMIS and all of your iMIS sites, which means that the URLs to the iMIS sites hosted on your iMIS application server all contain an /imis/ segment. (For example, http://www.myorg.org/imis/mywebsite). The Tips section below describes some methods you can use to manually create one or more IIS applications or even IIS web sites specifically for hosting your iMIS sites so that their URLs do not contain an /imis/ segment.

■ You must have administrative access to IIS and the entire file system on both the web server and on your iMIS application server, because in some scenarios you might need to manually copy some files that located on your iMIS application server.

If you installed your production iMIS application server using the Complete installation option, the application server has all the components needed to host iMIS sites. It is safe to use your iMIS application server to host private intranet sites for your organization. However, it is not recommended to use your iMIS application server for hosting your public-facing sites because doing so would expose the iMIS application to web clients outside your network firewall, which can pose security risks. Typically, you should instead host your public-facing iMIS sites on external web servers that are located outside your network firewall, and you should install only the iMIS code needed to support iMIS sites on those external web servers.

If your organization has a broad geographical presence, you might choose to use multiple external web servers in different geographic locations to provide load-balancing and improve geographic latency, as well as to provide different content for each geographic region.

The definition of an iMIS site, its sitemap and navigation items, and its content records exist in the iMIS database, and the site's graphics and files for download all exist in the file system of your production iMIS application server. The publishing mechanism of WCM renders all this source content into the various files that IIS needs to host the site, then places these files on each server that you specify should actually host the site.

You control which servers in your environment actually host the site through the URL(s) pointing to the IIS website root field in the site's definition. Each URL listed in this field must resolve to an IIS application or IIS web site on a server where you have installed WCM.

For example, if you want to host a site on both your production iMIS application server and an external webserver, the two URLs you would enter in this field would be something like: http://myimisappserver/imis/, http://www.myorg.org/wcm/. If the defined URL Name of this Website is mysite, then entering http://myimisappserver/imis/mysite in a web browser would view the site as hosted by your production iMIS application server, and entering http://www.myorg.org/wcm/mysite in a web browser would view the same site as hosted by your external web server.

To ensure that content for the site is rendered and copied to each server that hosts the site, the two halves of the publishing mechanism for each server must be correctly defined with a unique Publish Server Code. This is automatically configured by the iMIS installer if you specified a unique code for each server during installation, but because the iMIS installer defaults to a value of A for this code, you can inadvertently end up with duplicate Publish Server Codes in your production environment. The task Defining publishing servers explains how to correct this situation.

Assuming that the publishing mechanism is correctly defined for each of the servers that are hosting the site, all that's left in our example scenario is to specify the A and B codes (or the value All) that correspond to these publishing servers in the Publish on Servers field in the definition of each content folder that contains the content records whose rendered output we want to be available to the site on each server. When you publish a content record, it is this field in the parent content folder that determines which publishing services should process the new content record and place its rendered output in the file system on their server. This enables the site's navigation items to find the rendered versions of their corresponding content records in the local file system of each server.

Caution! The techniques described in this section can give you more control over the URLs that point to your iMIS sites, but this requires increased disk space requirements and increased maintenance overhead. These techniques involve manually creating additional copies of the Net folder that contains all the iMIS code that supports iMIS sites (roughly 1.6 GB of disk space required per copy). These additional copies cannot be detected by the iMIS Installer for software upgrades. After every iMIS upgrade that you install, you must therefore manually copy all files that were changed by the upgrade from the originally installed Net folder (and in all of its sub-folders) into the additional instances of the Net folder.

Note: If you use the techniques in this section to create additional IIS applications for hosting your iMIS sites, be sure to communicate the corresponding new URLs to those who define your iMIS sites, because they must specify these URLs in the URL(s) pointing to the IIS website root when defining sites.

In the preceding section, the iMIS Installer created a single IIS application for hosting all of your iMIS sites on the web server. You can alternatively use more than one IIS application for hosting your iMIS sites. To understand the potential benefits of doing this, let's examine how the URLs for your iMIS sites look when you use only one application to host all of them.

Assume that your organization's domain name is www.myorg.org, and that when you used the iMIS installer to install the Content Management component on a web server, you used the default name of WCM for the IIS application that will host your iMIS sites. You next defined two iMIS sites: one whose URL name of this website is USA, and the other whose URL Name of this website is EUROPE. For both of these sites, you specified http://www.myorg.org/wcm/ as their URL(s) pointing to the IIS website root. Finally, since both sites are hosted by the same IIS application, you specified the USA site to be the default site for this IIS application by selecting the Make this website the default checkbox.

Note: Regarding the first http://www.myorg.org/wcm/ URL in this scenario, the moment that you navigate away from the home page, the URLs will start showing the full URL, including the segment for the IIS application name, for subsequent pages: http://www.myorg.org/wcm/usa/[theRestOfTheURL].

You might decide that this dynamic URL rewriting behavior for several iMIS sites that are hosted by the same IIS application results in URLs that are too long or otherwise confusing to remember. In this case, you could simplify the URLs for your sites by manually creating a separate IIS application for each iMIS site. This removes the need to specify the extra URL segment that identifies the URL Name of this website.

The following process describes how to set up one such additional application. You must repeat this process for each application you add to the IIS Default Web Site:

1. On the application server or web server where you are creating the additional IIS application, you must first create a new copy of the Net folder that contains all the ASP.NET code used by iMIS. It doesn't matter where you put this copy of the Net folder, but your changes can be predictable to other administrators if you put each copy in a folder at the same level as your iMIS folder. So for example, you could create a new folder in C:\Program Files\ASI called WCM Sites, and then copy the entire Net folder (located by default in C:\Program Files\ASI\iMIS) into the WCM Sites folder, resulting in C:\Program Files\ASI\WCM Sites\Net. (You still have your original C:\Program Files\ASI\iMIS\Net folder as well.) This file path to the new copy of the Net folder is what you must specify as the Physical Path to the new IIS application in the next step.

2. In IIS on this server, add the new application directly beneath the Default Web Site, specifying an Alias that makes sense in the context of a root URL that points to your organization's sites. The Physical path must be the full path to the copy of the Net folder that you created in the previous step.The corresponding path credentials must be set to connect as the application user (pass-through authentication). If you are using IIS7 and later, you must also select the iMISApp AppPool to ensure that you are using the Integrated pipeline mode and sharing the same application pool as the other iMIS-related applications on the server.

3. In IIS on this server, the 404 redirect for the new application incorrectly points to the 404.aspx file in the root of the physical path for the application that was originally installed by the iMIS Installer (the original Net folder). For example, if you installed the full iMIS application as part of a Complete iMIS installation, the path for the 404 redirect specifies /iMIS/404.aspx (where iMIS represents the application name in IIS). You must replace this application name segment with the new application name, so that IIS will look in the physical path for your new application for the custom 404.aspx file. In IIS, open the Error Pages settings for the new web site and edit the 404 entry to Execute a URL on this site, with the URL specified as /[applicationName]/404.aspx. For example, if you named this new application with the alias USA, then this URL would be specified as /usa/404.aspx.

4. On this server, open a Command Prompt window and execute the following command to create a new instance of the publishing service to control publishing of content to this new physical path for the IIS application.

□ The path to the InstallUtil.exe utility provided with the ASP.NET framework assumes that you have installed the framework in the default location.

□ The [AsiPublishing15Secondary] string should be replaced by the specific name that you want to give to each additional instance of the publishing service.

□ The [file path to copied Net\bin folder] string should be the absolute path to the bin folder in the new copy of the Net folder that you created in Step 1. For example, C:\Program File\ASI\WCM Sites\Net\bin.

%WINDIR%\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe /ServiceName=[AsiPublishing15Secondary][file path to copied Net\bin folder]\PublishService.exe

5. Manually modify the Publish Server Code of this new instance of the publishing service to be unique among all publishing services in your environment, as described in Defining publishing servers. When you define a new publishing server, the Frequency and Publishing Speed values default to zero. You should set them to Frequency=10 and Publishing Speed=100.

6. Modify the configuration file for this new instance of the publishing service to listen on a different port than the one used by the default instance.

□ In the new copy of the Net folder that you created in step 1, edit the file ..\bin\PublishService.exe.config.

□ Locate the following element and change the port value to some unused port number in your environment.

7. Modify the search configuration file for this new application to communicate with the same port number that you specified for the new instance of the publishing service.

□ In the new copy of the Net folder that you created in step 1, edit the file SearchRemoting.config.

□ Locate the following element and change the port segment of the url value to the same port number that you specified in step 6b.

8. In the Maintenance section of Content Management, define a new publishing server to control the publishing service, as described in Defining publishing servers.

Assume that you have used this process to create two additional IIS applications: one with the alias USA, and the other with the alias EUROPE. Your two sites still have the same URL names as in the previous scenario (still USA and EUROPE), but the URL names won't matter because they are used only to differentiate among multiple sites when they share the same IIS site root. What's different in this scenario is that the USA site specifies http://www.myorg.org/USA/ as its URL(s) pointing to the IIS website root, and the EUROPE site specifies http://www.myorg.org/EUROPE/ as its URL(s) pointing to the IIS website root.

The following two URLs would also work but they are longer and contain redundancy, so there's no need to communicate these to your members or the general public. The last segment, which specifies the URL name of this website, is not needed by WCM to determine which site to display.

Caution! If the structure of your added IIS applications results in a situation where you have one IIS application that hosts iMIS sites nested inside of another IIS application that also hosts iMIS sites, you must remove some elements from their respective web.config files in all but the top-most application in this nested hierarchy. First, remove the <system.webserver> element. If its parent <location> element is subsequently empty (contains no other elements), then remove the <location> element too.

Note: If you use the techniques in this section to create additional IIS web sites for hosting your iMIS sites, be sure to communicate the corresponding new URLs to those who define your iMIS sites, because they must specify these URLs in the URL(s) pointing to the IIS website root when defining sites.

If you prefer to host an iMIS site at the level of an IIS web site instead of at the level of an IIS application, it is possible to do this by using a process that is very similar to that described in the preceding section. This technique enables you to create an even shorter URL for an iMIS site, such as http://www.myorgusa.org/ instead of http://www.myorg.org/usa/.

1. On the application server or web server where you are creating the additional IIS web site, you must first create a new copy of the Net folder that contains all the ASP.NET code used by iMIS. It doesn't matter where you put this copy of the Net folder, but your changes can be predictable to other administrators if you put each copy in a folder at the same level as your iMIS folder. So for example, you could create a new folder in C:\Program Files\ASI called WCM Sites, and then copy the entire Net folder (located by default in C:\Program Files\ASI\iMIS) into the WCM Sites folder, resulting in C:\Program Files\ASI\WCM Sites\Net. (And you still have your original C:\Program Files\ASI\iMIS\Net folder as well.) This file path to the new copy of the Net folder is what you must specify as the Physical Path to the new IIS web site in the next step.

2. In IIS on this server, add the new web site, specifying the Physical path as the full path to the copy of the Net folder that you created in the previous step. The corresponding path credentials must be set to connect as the application user (pass-through authentication). If you are using IIS7 and later, you must also select the iMISApp AppPool to ensure that you are using the Integrated pipeline mode and sharing the same application pool as the other iMIS-related applications on the server.

3. In IIS on this server, the 404 redirect for the new web site incorrectly points to the 404.aspx file in the root of the physical path for the application that was originally installed by the iMIS Installer (the original Net folder). For example, if you installed the full iMIS application as part of a Complete iMIS installation, the path for the 404 redirect specifies /iMIS/404.aspx (where iMIS represents the application name in IIS). You must remove this application name segment from the path so that IIS will look in the physical path for your new web site for the custom 404.aspx file. In IIS, open the Error Pages settings for the new web site and edit the 404 entry to Execute a URL on this site, with the URL specified as /404.aspx.

□ The path to the InstallUtil.exe utility provided with the ASP.NET framework assumes that you have installed the framework in the default location.

□ The [AsiPublishing15Secondary] string should be replaced by the specific name that you want to give to each additional instance of the publishing service.

%WINDIR%\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe /ServiceName=[AsiPublishing15Secondary][file path to copied Net\bin folder]\PublishService.exe

5. Manually modify the Publish Server Code of this new instance of the publishing service to be unique among all publishing services in your environment, as described in Defining publishing servers.

6. Modify the configuration file for this new instance of the publishing service to listen on a different port than the one used by the default instance.

□ In the new copy of the Net folder that you created in step 1, edit the file ..\bin\PublishService.exe.config.

□ Locate the following element and change the port value to some unused port number in your environment.

7. Modify the search configuration file for this new IIS web site to communicate with the same port number that you specified for the new instance of the publishing service.

□ In the new copy of the Net folder that you created in step 1, edit the file SearchRemoting.config.

□ Locate the following element and change the port segment of the url value to the same port number that you specified in step 6b.

8. In the Maintenance section of Content Management, define a new publishing server to control the publishing service, as described in Defining publishing servers.

Caution! if the structure of your added IIS web sites results in a situation where you have one IIS application that hosts iMIS sites or iMIS applications nested inside of an IIS web site that also hosts iMIS sites, you must remove some elements from their respective web.config files in all but the top-most IIS web site in this nested hierarchy. For example, this situation could occur if you configure the IIS Default Web Site on your production iMIS application server to host some intranet iMIS sites, because the iMIS application is one of the applications located in the IIS Default Web Site. First, remove the <system.webserver> element. If its parent <location> element is subsequently empty (contains no other elements), then remove the <location> element too.

The scenarios described in the preceding two sections illustrate the way that WCM performs dynamic URL rewriting.

To choose which files to serve up to a requesting web browser, the WCM code located in the physical path of the IIS application or IIS web site matches the requested URL to the URL(s) pointing to the IIS website root property of the various iMIS sites in the system. If there is only one iMIS site defined in the system that uses this requested URL, then the WCM code serves up the home page for that iMIS site to the requesting browser.

However, if the WCM code determines that there are multiple iMIS sites that share the same requested URL in their URL(s) pointing to the IIS website root property, it then parses the following URL segment and matches this value to the URL name of this Website property of the various iMIS sites in the system to determine which site's home page to serve up to the requesting browser.